The use of issue tracking software (ITS) to record and track the status of outstanding issues associated with a task and/or project is common place. An ITS typically creates a centralized database for tracking bugs, features, and inquiries as they progress from their initial creation to a final closed state. Examples of an ITS include bug tracking systems, help desk and service desk issue tracking systems, and asset management systems and may be implemented as a client-server application within distributed and hosted computing systems.
An ITS typically generates work items, which are artifacts that keep track of the tasks and issues that a team needs to address during a development cycle, such as a software development cycle. A work-item encapsulates all information pertaining to a single unit of work which needs to be completed for a development project and includes attributes, such as title and description, which communicate the nature of the task or issue. Further, a work-item depicts the status of the associated task at any time, tracks the effort expended on the work-item, and manages the work-item's review and approval workflow. Work items provide traceability between different reported issues. In general, a work item is an object that controls the process of performing work during, for example, software or systems development.
Work items have a life cycle, which concludes when the work item is closed (the end state). During the life cycle, a work item's state may be changed by adding data or changing the data of the work item, for example, by typing text, selecting values from a pick list, or adding attachments, by authorized persons with access control (permission) to the work item. In addition to generating work-items, an ITS typically also generates work-item notifications (hereinafter “notifications”) when the authorized person enters/modifies an attribute of a work item, discussed in further detail below. Further, an ITS transmits, typically via electronic mail, the notification to the person that is primarily responsible for the work-item (hereinafter “owner”) and all persons included in the subscriber list of the work item (hereinafter “subscriber”). The subscriber list is a list of persons that may contribute to the work-item.
Notifications include information regarding the updated work-item, such as who acted on the work-item, which attribute was edited, etc. Notifications can serve different purposes for different roles. Project managers may like to see many notifications to better assess activity and progress. On the other hand, some developers choose not to follow the team's individual progress (e.g. deliberately not change the status of work items to “in progress”) because this often generates many notifications that only help others to track their progress, and have no perceived benefit to the developers themselves. Current approaches to ITS require the developer to manually isolate important notifications from notifications of relatively low importance.
Current ITS solutions have introduced some rudimentary measures to support personalized work-item notification generation, but these measures require manual configuration. For example, one may choose to receive notifications concerning new comments but not notifications concerning work-items status changes. However, an update of any work-item attribute may not always be considered important from a user's perspective. Another alternative for tracking work-item updates requires a user to regularly visit dashboards that show recent activity on a list of work-items selected by certain criteria (e.g., ownership, subscription status, labeled by a particular category or tag). Again, such an approach requires the user to manually browse multiple dashboards to assess which work-items need attention.